1. Field of the Invention
The present invention relates generally to networking systems. More particularly, embodiments of the invention relate generally to the testing of high speed data transmission systems and components.
2. Background Technology
Computer and data communications networks continue to proliferate due to declining costs, increasing performance of computer and networking equipment, and increasing demand for communication bandwidth. Communications networks—including wide area networks (“WANs”), local area networks (“LANs”), metropolitan area networks (“MANs”), and storage area networks (“SANs”)—allow increased productivity and use of distributed computers or stations through the sharing of resources, the transfer of voice and data, and the processing of voice, data and related information at the most efficient locations. Moreover, as organizations have recognized the economic benefits of using communications networks, network applications such as electronic mail, voice and data transfer, host access, and shared and distributed databases are increasingly used as a means to increase user productivity. This increased demand, together with the growing number of distributed computing resources, has resulted in a rapid expansion of the number of installed networks.
As the demand for networks has grown, network technology has developed to the point that many different physical configurations presently exist. Examples include Gigabit Ethernet (“GE”), 10 GE, Fiber Distributed Data Interface (“FDDI”), Fibre Channel (“FC”), Synchronous Optical Network (“SONET”) and InfiniBand networks. These networks, and others, typically conform to one of a variety of established standards, or protocols, which set forth rules that govern network access as well as communications between and among the network resources. Typically, such networks utilize different cabling systems, have different characteristic bandwidths and typically transmit data at different speeds. Network bandwidth, in particular, has been the driving consideration behind many advancements in the area of high speed communication systems, methods and devices.
For example, the ever-increasing demand for network bandwidth has resulted in the development of technology that increases the amount of data that can be pushed through a single channel on a network. Advancements in modulation techniques, coding algorithms and error correction have vastly increased the rates at which data can be transmitted across networks. For example, a few years ago, the highest rate that data could travel across a network was at about one Gigabit per second. This rate has increased to the point where data can travel across Ethernet and SONET networks at rates as high as 10 gigabits per second, or faster.
As communication networks have increased in size, speed and complexity however, they have become increasingly likely to develop a variety of problems that, in practice, have proven difficult to diagnose and resolve. Such problems are of particular concern in light of the continuing demand for high levels of network operational reliability and for increased network capacity.
The problems generally experienced in network communications can take a variety of forms and may occur as a result of a variety of different circumstances. Examples of circumstances, conditions and events that may give rise to network communication problems include the transmission of unnecessarily small frames of information, inefficient or incorrect routing of information, improper network configuration and superfluous network traffic, to name just a few. Such problems are aggravated by the fact that networks are continually changing and evolving due to growth, reconfiguration and introduction of new network topologies and protocols. Moreover, new network interconnection devices and software applications are constantly being introduced and implemented. Circumstances such as these highlight the need for effective, reliable, and flexible diagnostic mechanisms.
As shown in FIGS. 1-3, certain prior art networking systems included one or more nodes (such as servers or data storage devices) communicating with each other. To test networking systems like these, protocol analyzers, monitors, and/or other network diagnostic modules were arranged in various configurations, such as the configurations shown in FIGS. 1-3. As shown in FIGS. 1-3, a link may be provided for each data source, and each data source may communicate via their respective links. Unfortunately, configurations like shown in FIGS. 1-3 could be expensive to purchase and time consuming to install.
For example, as shown in FIG. 1, to test communication to and from a data source, a monitor is coupled to the data storage device's link, and a protocol analyzer is coupled to the monitor. Thus, if there are d number of data storage devices (and d number of links to be tested), this configuration includes d number of monitors and d number of protocol analyzers.
While the configuration shown in FIG. 1 allows each link to be tested 100% of the time, monitors and protocol analyzers can be expensive—making the configuration shown in FIG. 1 impractical for many businesses, especially as the number of data storage devices increases. Accordingly, some businesses may choose to couple a monitor and/or a protocol analyzer to less than all of the links, allowing some of the links to be tested 100% of the time while other links are not tested at all. Unfortunately, testing less than all of the links may cause certain problems on the untested links to remain undiagnosed. Moreover, to test different links, the monitor and/or the protocol analyzer must be physically disconnected from their current link and reconnected to the new link—a time consuming process that can create wear and tear on the connection components.
As shown in FIG. 2, a tap may be used to allow a monitor and/or a protocol analyzer to be shared among a plurality of links. For example, an 8-port tap is coupled to eight links corresponding to eight data storage devices. A monitor is coupled to the tap, and a protocol analyzer is coupled to the monitor. To test communication to and from the data storage devices, the monitor may use the tap to “rove” from one link to another link. Testing only one link at a time via the tap, the monitor may rove among the links to allow any or all of the links to be tested (albeit for a percentage of the time). Thus, the configuration shown in FIG. 2 advantageously allows a monitor and/or a protocol analyzer to test any of 8 links.
Unfortunately, in the configuration shown in FIG. 2, the monitor may not rove away from a link while the protocol analyzer executes a bit capture on that link. Instead, the monitor disadvantageously waits until the protocol analyzer finishes the bit capture—meaning that the other links coupled to the monitor's tap are not monitored during the bit capture. Further, in the configuration shown in FIG. 2, while the protocol analyzer executes a bit capture on one link, the protocol analyzer may not execute another bit capture on another link—meaning that the bits on the other links coupled to the monitor's tap are not captured. Consequently, certain problems on these other links remain undiagnosed.
As shown in FIG. 3, a plurality of taps may be used to allow a protocol analyzer to be shared among a plurality of monitors with each monitor shared among a plurality of links. In particular, a protocol analyzer is coupled to a first 8-port tap. The first 8-port tap is coupled to eight monitors. Each monitor is coupled to an 8-port tap that is coupled to eight links corresponding to eight data storage devices. Accordingly, the configuration shown in FIG. 3 advantageously allows a protocol analyzer to test any of sixty-four links. Also, like the configuration shown in FIG. 2, the configuration shown in FIG. 3 advantageously allows an individual monitor to test any of eight links.
Unfortunately, in the configuration shown in FIG. 3, a monitor may not rove away from a link while the protocol analyzer executes a bit capture on that link. Instead, the monitor disadvantageously waits until the protocol analyzer finishes the bit capture—meaning that the other links coupled to the monitor's tap are not monitored during the bit capture. Further, in the configuration shown in FIG. 3, while the protocol analyzer executes a bit capture on one link, the protocol analyzer may not execute another bit capture on another link—meaning that the bits on the other links coupled to the monitor's tap (and the bits on the links coupled to the other monitors' taps) are not captured. Consequently, certain problems on these other links remain undiagnosed. In addition, the configuration shown in FIG. 3 may include several taps and related physical connections that can disadvantageously increase the overall cost of purchasing and installing the networking system.
In addition, using the 8-port taps, the configurations shown in FIGS. 2 and 3 may test up to 8 links and 64 links, respectively. Unfortunately, some businesses may have networking systems that include significantly more links than 64 links—meaning that businesses using the configuration shown in FIG. 2 or 3 must either purchase more and more protocol analyzers, taps and monitors (in order to repeat those configurations) or must allow only some of their links to be tested while other links are not tested at all.